基于资产配置业务场景下的全链路监控平台
每年夏秋交错之时总会非常的忙碌，也许是因为久违的那一丝丝凉意秋风，也许是……今年的年度规划来的稍早了一些……
和往年一样，在这个季节里，也是各大盛会聚集的时刻，就在刚刚过去的CNUTCon中，亲身感受了圈内运维伙伴们的热情洋溢，除此之外，我也在互金专场中为大家分享下好买财富在全链路监控上的那些事
未来已来
无论是《终结者系列》中那些震撼的场景，还是AlphaGo击败人类的那一刻画面，相信没有人会怀疑人类已进入了智能时代
那么，智能化资产配置是啥意思？
利用AI技术，将投资金额分散在不同理财中，从而最终达到预期收益的方式
好买已在今年发布了 基于智能投顾业务场景的机器人：
测试风险偏好
选择资产配置（定制化）
买入与卖出再平衡
波动平衡
观点平衡
拉杆平衡
既然未来已来，咱们运维，该如何面对？
我们为什么需要全链路监控？
从去年开始，为了应对互联网特性的与日俱增，我们将策略调整为「快速交付」与「快速排障」，并针对其开展全维度的执行
某某大神说过： “梦想总是伟大的，现实总是残酷的”
先来说说「快速交付」：
老板：怎么才能快？
运维：松耦合
老板：怎么才能把现在的系统变为松耦合？
运维：拆！拆！拆！
老板：最终，耦合是越来越松了，系统数量却越来越多了，当然链路也就随之加长了，怎么办？
运维：………………老板，你好懂
甚至最后变成……
47 31681 47 14941 0 0 3863 0 0:00:08 0:00:03 0:00:05 3862某大神又说过： “不能给业务带来价值的技术都是耍流氓，快了，老出问题有毛用”
再来说说「快速排障」：
随着系统越来越多，链路越来越长，当故障出现的时候，那么多系统，谁有能力一眼看出究竟是哪个系统在捣鬼？
靠人品？还是拼技术？
这套全链路监控的实现原理是什么？
和大多数公司一样，所谓的全链路监控，无非就是「基于网络调用日志的分布式跟踪系统」罢了
在与其他公司交流中，发现大多数公司都采用ELK来进行日志收集与分析，由于 “历史性” 原因，我们选择自研收集器与分析引擎，整体架构可分为「五个层次+四个模块」：
日志结构与如何埋点：
UUID含义是通用唯一识别码 (Universally Unique Identifier)，整个链路的TraceId都是围绕UUID展开的
来一张Log Sample：
这套全链路监控的长啥样？
下面是系统的部分截图与注释说明：
展望未来，还有很长的路要走……
从年初的第一个版本上线至今，无论在「快速交付」或在「快速排障」中，都极大地提升了效率
无论从金融的视角，还是从互联网的视角，大部分系统的发展都是从一个坑跳到另外一个坑，然后再把原来的坑填满，填着填着，架构就这样奇妙的产生了
在第二个版本研发过程中，会对以上四点进行增能：
血缘分析：从错误点推导全链路，并分析出导致本错误点的原因
调用还原：增加快照功能，支持上一节点的调用回放功能
容量评估：暂定位日志存储容量的评估（本功能未考虑清晰）
原因定位：目前只能定位到某个接口失败或错误，并将错误与异常的信息打印出来，本功能将支持失败归因，后期将考虑自动修复
全自研的PaaS运维平台
其实，实现这些功能也好，迈向FT也罢，所谓平台化，是一种体系，也是一种目标，好买在DevOps的路程中只能称得上刚刚起步，但是梦想必须要远大，万一成功了？那不是挺好玩吗？
(图中绿色部分是链路监控在DevOps中的位置)
故事已讲完，迈步才开始
运维与跑步，都是一项体力活，运维期望服务能够稳定运行，跑步期望身体能够高效跨步。
想要取得这种 “期望”，无论身体还是技术，与长期有效的训练是密不可分的，但击败我们的，不是难度与深度，而是耐心……
近期发表文章：
扫描二维码或手动搜索微信公众号【吃草的罗汉】
欢迎转载，带上以下二维码即可
点击“阅读原文”，所有【吃草的罗汉】近期的文章汇总
↓↓↓